perm filename CAR.B[P,JRA] blob
sn#396748 filedate 1978-11-18 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00003 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 \\M1BASL30\M2BASB30\M3NGR25\M4NGR20\M5BASI30
C00005 00003 batch-processing systems are inferior to conversational systems that
C00017 ENDMK
C⊗;
\\M1BASL30;\M2BASB30;\M3NGR25;\M4NGR20;\M5BASI30;
\F1\COct 2, 1978
interested in some articles on LISP from \F5me\F1? I am resurrecting my
"LISP-for-the-micros" articles and, since you had begun work on them,
thought you should have right of first refusal.
\\M1BASL30;\M2BASB30;\M3NGR25;\M4NGR20;\M5BASI30;
\F1\COct 2, 1978
I can assure you that this time the process wil be smoother. Before, I was
doing battle both with McGraw-Hill and Hewlett-Packard.
(Hum, I wonder if I've got something against corporations with hypenated
names?)
McGraw-Hill decided to
use my book and my knowledge as "an experiment in computer typesetting".
One of their minions was supposed to take my machine-text, with instructions
from me, and develop the translation process; he was a "computer expert".
Six months later he was still flying around the country, looking for a
software house which could write the program; it soon became clear that
he had not even read the instructions I had prepared. More upsetting,
it was clear that this schedule would delay the publishing date to the next
academic year. Therefore, the only way it would get done was if I did it
myself in the very wee hours of the morning; that did not please me at all.
Finally, I wrote the typesetting program for McGraw-Hill, and
was assured by the
compositor that everything was ok. I punched twenty-four boxes of paper
tape, only to discover that the compositor was unable to generate consistent output.
Simultaneously, I was trying to convince the "research lab" of HP that
batch-processing systems are inferior to conversational systems; that
2400 baud glass teletypes are not interactive displays; that an HP3000 is
\F5not\F1 a "machine like the PDP-10, but with 16-bit words" (the manager
of the advanced software section actually said that to John McCarthy!);
that if I was to build a machine which executed LISP well and was attractive to
the AI community, the project would require a staff which understood these problems.
This is the kind of turmoil which you walked into; both problems have been
resolved: I told McGraw-Hill to forget their "computer experiment" and use
the XGP output; the book is now available.
I quit at HP, and I am now available too.
Now I would like to return to the pleasurable and important
task of describing the benefits of LISP-like languages to the personal
computer crowd.
I have been following the Pascal articles in BYTE with some interest.
I would like the opportunity to present my LISP philosophy
as a contrasting position.
It seems to me that the Pascal-like languages do very little to reinforce
the creative process of algorithm discovery and creation. They, like most
traditional computer languages, are more concerned with the \F5execution\F1
of already constructed algorithms. This is a natural outgrowth of their
ancestry: a numerical computational era in which the emphasis was placed
on minimizing computer time at the expense of programmer time. Times and
economics have changes. Computers are cheap and programmers are expensive;
we need techniques to speed the development of correct programs.
Certainly the verification efforts are aimed in this direction, but verification
typically is an after-the-fact reconciliation of a completed algorithm
versus some descriptive specification of its behavior.
We need languages which support the creative and exploratory phases of
program development.
Exploratory programming, which is the hallmark of AI and which,
to a very large extent, occurs in the creative stages of any programming
task, is best done with an un-typed interactive language like LISP.
Strong typed languages like Pascal only
confuse and obfuscate the formulative stages.
We must put a stronger emphasis on the education of programmers, rather
than restrict the expressive powers of the languages. Consider the tools of a
more traditional craftsman: in the hands of an amateur those tools can be
deadly, whereas the craftsman can develop exquisite objects. Does one
propose that all tools be dulled appropriately so that the amateurs cannot
do themselves injury? No, we educate them in the proper use of, and respect for,
the instruments and expect that the craftsman's tool remain sharp.
The emphasis is properly placed on the individual.
I don't advocate that
programmers's who produce buggy code be shot, but I do insist that
we take better efforts to educate our people. In this regard, I find the Pascal
approach a false temptress; do not be tempted to dull the tools of the programmer
by the appealling arguments of fast parsing algorithms and efficient compilers;
do not begin to confuse education with the
mass-merchandizing of armies of programmers
whose competence is sealed in a cautious, uncreative world of dull tools.
Rather be seduced by LISP, whose bizarre advocates have created some of the
most elegant computer related products. Not everyone should program
in LISP; in fact, not everyone should program. However the AI community
is the craft of the tool builder; their tools are the sharpest and most
incisive of the computer field. It is this kind of tool which should appeal to
the personal computer person. It is not the elegance of BASIC which has
made it the standard personal computer
language; it is BASIC's interactive nature, allowing
quick experimentation with programming ideas, which accounts for its
longevity. Much of this interactive flavor can be grafted onto an Pascal-like
language, but the result is much inferior to what one can expect from a
true interactive language like LISP.
In fact, the spirit which created Pascal was opposed to interactive computation:
Wirth, in the 1969 Software Engineering Conference said \F5"I would like to discuss
the trend towards conversationality in our tools. There has been, since the
development of timesharing and on-line consoles, a very hectic trend towards
development of systems which allow the interactive development of
programs. Now this is certainly nice in a way, but it has its dangers, and I
am particularly wary of them because this conversational usage has not only
gained acceptance among software engineers but also in universities where students
are trained in programming. My worry is that the facility
of quick response leads to sloppy working habits and, since
the students are going to be our future software engineers, this might be
rather detrimental to the field as a whole".\F1
Wirth may have modified his position since then, but when Pascal
was formulated, he was not an advocate of interactive programming.
Many of the decisions and compromises of Pascal are a result of his
view of computation.
I feel it is important that the personal computer
users understand that they need not give up the interactiveness of BASIC
to gain the structure and portability which Pascal is advertising; LISP
offers both. LISP is \F2not\F1 a special purpose list-processing language,
as MACSYMA's arithmetic, Teitleman's development system, and Greenblatt's
LISP machine demonstrate. Its compilers can be as good as those of any
other language;
its development systems are far superior to those of other
(well-known) languages; it can be used as an effective systems programming language,
as well as being the entry point for all of AI and much of the theory of
computation. it is this content and philosophy which I hope to elaborate in my
articles.
It is particularly important to influence the personal computer
advocate now, given the growth of Pascal-like like languages, the
rising specter of DOD-1.
I expect that the Pascal phenomenon will run its course like the New Math
rage; much will be learned, but the lessons will be expensive. I would hope
that my articles will at least spare the personal computer groups from some of
that misery.
On the positive side, the emergence of the new class of micro computers is
particularly exciting: micros with the power of a mini. This will open up
many new areas, including AI, for the personal machine.
The new machines
will support very substantial implementations of LISP;
many new areas, including AI, for the personal machine.
even today there are
versions of LISP for the Z-80, 8080, 6800, F8, and a APPLE/BASIC version.
BYTE readers should be exposed to concepts in these implementations.
I kept the edited manuscript which you returned to me; I am ready to rewrite
that initial article and supply a total of about six, covering most of the
details of LISP programming and micro implementations. I await your response.
I'm sorry that our past attempts at communication have been so noisy; I hope
that we can try again.
\.
\←L\→S\←R\-L\/'2;\+L\→L
Yours sincerely,
John R. Allen
18215 Bayview Dr.
Los Gatos Ca. 95030
408 353-2227
\←S\→L